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A robotics systems design need: a design standard to 
provide the systems focus that is required for longterm 

exploration efforts. 


ABSTRACT 

The United States is entering a new period of human 
exploration of the inner Solar System, and robotic human 
helpers will be partners in that effort. In order to support 
integration of these new worker robots into existing and 
new human systems, a new design standard should be 
developed, to be called the Robot-Systems Integration 
Standard (RSIS). It will address the requirements for 
and constraints upon robotic collaborators with humans. 
These workers are subject to the same functional 
constraints as humans of work, reach, and 
visibility/situational awareness envelopes, and they will 
deal with the same maintenance and communication 
interfaces. Thus, the RSIS will be created by discipline 
experts with the same sort of perspective on these and 
other interface concerns as human engineers. 


INTRODUCTION 

Is has been thirty-two years since humans last walked 
on another planetary surface or even left Low Earth 
Orbit. That last effort was intentionally short-duration; 
the Apollo mission goals did not include permanent 
human presence in space. In the intervening years, 
Europeans, Americans, and Russians have tested and 
demonstrated a technical capacity to perform short and 
long-term operations in space; the International Space 
Station represents a continuation of the Soviet intention 
to establish a permanent presence. At the same time, 
robotic exploration of the Solar System has continued to 
characterize the environments humans will eventually 
enter. For all of this time, there has been a constituency 
in all the spacefaring nations for long-duration human 
presence beyond Low Earth Orbit. There has been little 
support for this effort among the space agencies, 
however. Certainly part of the reason for this has been 
the fear on the part of these agencies of program 
cancellation. There has also been a sense that an 
“Apollo-type" program lacks staying-power, by its very 
nature, and that sense has caused temerity about 
repeating these types of human missions, which might 
result in withdrawing from the field for a very long time. 
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In January 2004, United States President George Bush 
proposed an incremental approach to exploration that, if 
properly implemented, would develop the infrastructure 
for exploration as steps are made and provide 
opportunities for staying, rather than withdrawing. This 
effort will take advantage of technologies that have been 
developed for terrestrial purposes. Among these is the 
use of worker robots that will be assistants to and 
caretakers for human space explorers. These robots will 
need to fit into a vast system architecture that includes 
habitats, human work areas, and exploration vehicles. 
They will need to be able to interface with these systems 
appropriately, in order to perform their desired functions. 
The most logical way to assure the robot designs 
conform to the mission, and hence system, requirements 
is to develop a design standard for robots. 

RATIONALE 

PRECEDENCE OF STANDARDS FOR HUMAN- 
CENTERED DESIGN - Humans are extremely complex, 
but this has not prevented the development of standards 
for the design of systems with which we interact. In the 
case of design of spacecraft, the need for such 
standards was recognized as early as 1966, when NASA 
published MSFC-STD-267A 1 . This and like documents 
eventually evolved into the Man-Systems Integration 
Standards (MSIS), NASA-STD-30 00 2 . This document is 
an Agency-wide standard and thus applies to all NASA 
human spaceflight programs. That is, the requirements 
for new programs, such the International Space Station, 
are derived directly (“flowed-down") from this document. 
It covers development of all hardware that humans in 
NASA vehicles interact with in Low Earth Orbit, from the 
space vehicles themselves to the payloads that 
astronauts manipulate to tools required for the 
deployment and maintenance of these systems. 
Specifically, it defines the bounds for workstation layout, 
communication methodologies, and life support, for both 
intravehicular and extravehicular activities. In support of 
these requirements, it fully documents human 
capabilities in the space environment, including 
anthropometry, flexibility and reach envelopes, resource 
requirements, temperature tolerance, and radiation 
susceptibility. This background is important for the 
establishment of the design requirements, and it is often 


essential to their interpretation. The creation of these 
standards very likely seemed unnecessary at the time 
they were developed. Even today, they are seen as 
statements of "common sense” (a capability the authors 
find startlingly uncommon) for which no requirement is 
necessary, and the claim is often made that they are 
constrictive of design creativity. Nevertheless, their 
contributions to mission success and prevention of loss 
of life are well established. 

ANALOGY BETWEEN ROBOTICS SYSTEMS AND 
HUMAN SYSTEMS - Collaborative, or helper, worker 
robots will perform many of the same functions as 
humans, except that they will not often work completely 
autonomously, at least in the nominal mission. In this 
sense, they will act as assistants to the human, as an 
apprentice might. Some will carry tools and other 
supplies and provide the proper one when called for. 
They will display procedures and other technical 
information for humans performing maintenance tasks or 
conducting science. On planetary surfaces, some will 
serve as carts for the human and for the units being 
maintained; that is, they will transport spare parts to be 
changed out and return the worn-out or damaged parts 
to a depot. During maintenance missions, they will team 
with humans, dividing tasks with them, once a certain 
level of robotic sophistication is reached. Some will 
serve as search-and-rescue and medical technicians for 
humans and for other robots. Some highly specialized 
robots will serve as medical assistants for complex 
procedures, being teleoperated by physicians remote to 
the exploration system 3 . 

These worker robots will be subject to the same 
functional constraints as humans of work, reach, and 
visibility/situational awareness envelopes. That is, they 
must be able to fit into a work area, reach the worksite to 
be actuated, and perceive both the location of the 
worksite and its qualities: bolt head size and condition, 
lever position, whether a cover is present, and so forth. 
They will deal with the same maintenance and 
communication interfaces as humans. That is, they will 
demate and mate electrical, data, and fluid connectors. 
They will actuate bolts and other fasteners. They will 
remove and replace components. Finally, they must 
obtain procedures for these and other tasks from 
external sources and store the procedures in memory. 
Each of these tasks is, of course, an analogue to human 
tasks, and each task implies a set of requirements. The 
similarity to the MSIS should not be missed; the design 
requirements associated with human task performance 
were derived from scenarios of the tasks that humans 
might be expected to perform in Low Earth Orbit. An 
understanding of the function of and tasks to be 
performed by helper robots will drive out the 
requirements those tasks imply. This definition of the 
tasks, in the form of a Critical Task Analysis, is a typical 
responsibility of the Human Engineer during the 
requirements definition phase of a design project 4 . This 


process ordered and reduced the scope of the otherwise 
seemingly boundless job of developing requirements for 
human design, and the same methodology should be 
employed for requirements relating to robots. 

PREVIOUS ROBOTICS STANDARDS - Early in the 
International Space Station program, a robotics standard 
was developed and titled the Robotics Systems 
Integration Standard 5 . This document described only 
standards for robots associated with the Station program 
and was thus limited in scope. In NASA parlance, it was 
a “Level II” document: one associated with a single 
program within a single agency. While the document 
began to address many of the issues that must be 
considered for a general robotics standard, it did so only 
within the context of the extant Space Station. The 
proposed standard would be superior to the program 
and could even be superior to the agency. It could be 
developed by and agreed to by the various partners 
collaborating in the exploration effort. Whether done at 
the agency level or at the international partner level, it 
naturally will be much more general and broad-ranging 
than the International Space Station standard. 

OTHER EFFORTS - Introductory texts in robotics (e.g., 
6, 7) address primarily the theory of design of a single 
robot. Discussion of integration of several to many 
robots into a system is limited to the development and 
operation of production lines. This is consistent with the 
current state of capabilities of robots and of designers to 
develop them. However, the types of interactions that 
the proposed new standard would address are beyond 
the highly repetitive and tightly-constrained tasks of the 
production line robots, and they imply considerably more 
collaborative capabilities than are found in existing 
mobile robots. The standard would address the ways 
robots interact with each other, with humans, and with 
other system-level hardware and software (here, 
“exploration system” refers to uncrewed planetary 
satellites and propulsion systems, as well as inspace 
and planetary crewed modules). It is important to 
emphasize that this standard will require no particular 
capability of individual robots and that it will not attempt 
to describe how to build a robot. Rather, it will allow 
robots to be designed so that they conform to the 
exploration system in an integrated way. This is 
important both in the near-term and as advanced 
capabilities are developed. Thus, there would be no 
requirement that a robot be developed that is capable of 
carrying out a complete search-and-rescue mission for a 
missing and injured human in a completely autonomous 
manner. It is conceivable that such a worker will 
become available at some time in the future, but all the 
capabilities implicit in this sort of mission scenario will 
not appear at once. In fact, the first helpers can 
reasonably be expected to have a level of capability that 
is only slightly greater than that of the robotic arm on the 
ISS or of the Spirit rover, each of which requires a 
human operator. The point of the standards will be to 


assure that the functionalities that exist are properly 
integrated into the exploration system and that new 
features can be added seamlessly as they become 
available. 

APPLICABILITY - The proposed document should be 
known as the Robotics Systems Integration Standards 
(RSIS), to allow it to be recognized as an agency-level 
(“Level I”) document analogous to the MSIS. It will 
address worker robots which operate collaboratively with 
humans, even though they may ultimately possess a 
great deal of autonomous capability. These helper 
robots will be those that support human activities, by 
assisting in and performing maintenance tasks on the 
exploration system by acting as research assistants, and 
by serving as life-protection and safety devices for 
humans. Since this type of robotic assistant will be part 
of essentially all future space systems, this volume will 
have far-flung ramifications. 

LIMITATIONS - It is recognized that such a standard 
cannot apply to all conceivable robots, and design 
solutions for some robots would be constrained if the 
standard were made applicable to all robots. The idea is 
that robots that fit the “worker” category should be 
subject to the standards. The criterion is whether 
humans or exploration system resources need to 
interface directly with the robot. Thus, fully-autonomous 
explorers, which never encounter humans once released 
or which do not require maintenance or resources if they 
do, would not be subject. Likewise, it is easy to imagine 
robots which are constantly in the human environment 
but for which the RSIS would be inappropriate. For 
example, free-living, centimeter-sized cleaning devices 
or expendable snake robots for exploring small spaces 
might be useful. Since these do not conform to the 
“Helper worker model,” both of these and similar 
independent robots would be exempt, or the standard 
would be applicable only to the extent that they are not 
independent; e.g., resource-allocation requirements 
might apply, if these robots depend upon power supply 
from the exploration system. 

Both the MSIS and the RSIS have the goal of assuring a 
well-integrated system with a high likelihood of mission 
success, and the development of the two documents can 
follow similar paths. The MSIS defines the constraints 
on system design that are imposed by human limitations 
and capabilities. Robots do not have the same 
limitations, but they do have limitations. A major 
undertaking of the development of this document must 
be the characterization of these constraints. The human 
constraints and capabilities described in MSIS constitute 
what designers often call “common sense,” but a cursory 
reading of the document reveals many features of 
human physiology and psychology that are, in fact, not 
intuitive. Similarly, the definition of the limitations and 
capacities of robotic helpers will form the assumptions 
upon which the requirements are based. Since these 


requirements will have a profound impact on the 
evolution of helper robots over the course of many years, 
their development is an important task. Some might 
argue that freedom to create a variety of systems will 
result in the best technical solutions, but there is little 
historical evidence to support this thesis. Many familiar, 
if simplistic, examples of this can be found in the field of 
consumer electronics. For example, while Betamax© 
was widely regarded as the superior commercial video 
recording technology in the 1970s, it has essentially 
disappeared today. 

STRUCTURE OF RSIS AND TOPICS TO BE 
ADDRESSED 

There should be three volumes in the initial release of 
this document. The first will deal with the design 
considerations and design requirements for the 
assembly and integration of worker robots. The second 
should address the design considerations and design 
requirements for development of subsystems and 
components to be manipulated by (maintained, 
transported, or stowed by) robots. The third will be a set 
of appendices addressing the sources of the 
requirements found in the other two volumes, glossaries, 
acronym lists, unresolved issues, and the like. 

VOLUME I - The first volume will describe a 
standardized set of robotic functions, capabilities, and 
constraints. It will relate these to mission concepts and 
to interfaces with other hardware and software, in order 
to define the requirements for robot design that support 
the mission goals. Sections of the volume will address 
propulsion, guidance and navigation, command and 
control, communications, mechanisms, end effectors, 
and sensors. There should be at least one section each 
that addresses interfaces with humans, other worker 
robots, and exploration system hardware and software. 
Note that the section on human :robot interfaces is 
critical. It is expected that, in addition to performing 
other tasks, some robots will transport or be transported 
by humans, some will provide them temporary life 
support, some will perform surgery, some will act as task 
assistants, and most will understand and react to human 
commands (verbal, as well as digital) and provide 
information to humans in understandable formats. 
These aspects of the standards will need to be 
addressed in human/computer interface standards of the 
MSIS, as well as in this volume. 

In addition, there will be at least one section on 
requirements for maintenance of the robots by humans 
(and, ultimately, other robots), but this will only address 
those requirements that are unique to robot maintenance 
and are not found in the MSIS. It should be noted, 
however, that the MSIS may need to be revised. One 
goal for maintainability of all hardware, robot and 
exploration system, will be that tool interfaces will be 
consistent across maintenance workers. That is, 


humans and worker robots should expect to encounter 
exactly the same tool interfaces when they approach a 
worksite, whether it be a power supply subsystem site, a 
robot rover cart, or a habitat environmental control 
subsystem. Limitation of the number of tools required to 
perform tasks is a primary goal of the development of 
this standard, so there will be a section on tool definition. 
This is important for several reasons: tools, while small 
compared to modules, are mass that must be lifted from 
the earth for the foreseeable future and are therefore 
costly; tools must be transported to a worksite, and the 
capacity of a toolbox, even on a rover robot, is limited; 
and keeping the number of tools needed for a task small 
reduces the likelihood that workers will arrive at the 
worksite with the wrong tool! One section will address 
the levels of autonomy a particular design can achieve. 
Many robots may be assemblable from a standard 
design to meet the mission goals. That is, the various 
subsystems for classes of robots should be available for 
a mission designer basically off-the-shelf. This sort of 
standardization will reap huge benefits for long-duration 
missions in logistics and spares, maintenance, and 
ground and flight crew training. While this approach can 
result in a wide variety of individual robots, the assembly 
from off-the-shelf components makes them more 
affordable and more reliable. The flow-down benefits to 
short-term missions and the design of free-existing 
robots are apparent but are not drivers. 

There may need to be special sections of Volume I to 
address special topics. For example, search-and-rescue 
robots may form a special class and need to be 
addressed separately. Also, other scenario-derived 
requirements may surface, such as the need for some 
workers to have transponder capability, to allow humans 
and other robotic workers to work outside line-of-site of 
the base station. 

VOLUME II - Design requirements for developers of 
exploration systems that will be serviced by robots will 
be covered in the second volume, This volume is, for all 
practical purposes, analogous to NASA-STD-3000 in its 
impact on design. All designers of subsystems with 
which robots will interface will need to conform to this 
volume. It will address the work envelopes that the 
standard robots must perform within, the strength 
capabilities of these robots, the interfaces they are 
capable of dealing with on the hardware to be 
manipulated (fluid, electrical, and data connectors; 
fasteners; volumes and dimensions; etc.), as well as the 
structural and thermal characteristics of the hardware. 
These are in almost every way analogous to the design 
issues addressed in NASA-STD-3000. This is because 
humans and robots face the same sorts of constraints 
when performing tasks; both must be able to detect 
(“see,” in the case of humans) and reach a hardware 
interface to manipulate it, and the manipulable 
component must conform to the constraints of the 


human ( e.g hand size, strength) or robot (e.g., tool 
fitting size, cybernetics). 

VOLUME III - This book will contain ancillary data, 
analogous to that in MSIS Vol. II. This is the background 
information that documents how requirements in the 
other volumes were derived. It will thus contain an 
operations concept section, which includes various robot 
mission scenarios which form the basis of the 
requirements. This section is critical to the development 
process. It is analogous to the task analysis 
development of the Human Engineer 4 and the scenario- 
based requirements development of the systems 
engineer 9 . It will also list all reference information and 
the specific requirements they apply to. Another section 
will provide notes documenting the thought processes of 
the requirements development team; that is, it will 
document, in everyday language, what the team thought 
the requirement meant at the time of development. This 
volume will serve as a reference for developers of robots 
and other systems, who must interpret the design 
requirements in the context of their own mission 
requirements. Glossaries, acronym lists, open issues, 
and other relevant information should also be put into 
Volume III. 

SYSTEM COMPLEXITY AND RISKS 

All human exploration involves risk, and complex 
systems are inherently risky. Failures in the NASA 
Space Shuttle Programs provide tragic demonstrations 
of the effects of the combination of these sources of risk. 
Many other failures of complex systems can be cited; 
among the most disastrous are the control room failure 
at the Three Mile Island nuclear power facility and the 
shooting down of the Iran Air passenger liner by the USS 
Vincennes. Both accidents occurred because of poor 
system design, particularly design of the human :machine 
interface 8 . When it is first developed, any conceivable 
exploration system will be arguably the most complex 
system yet created by humans, as ISS is today. Robots 
will not only add to that system complexity, they will be 
among the most complex individual components of it. 

The exploration effort will face a myriad of risks derived 
simply from the novel environments entered. It can ill 
afford complexity-driven risks. These cannot be 
completely avoided, but they can be managed. An 
axiom of systems engineering is that one of the most 
effective ways to mitigate the risks in complex systems is 
through thorough process-driven requirements 
development early in the program. This is the primary 
purpose of the RSIS. It should be developed early in the 
design phase of the exploration program and then levied 
on all exploration systems. The failure to create such a 
standard early in an exploration program will at the least 
result in the very high operations costs associated with a 
poorly-integrated system. A much more serious 
consequence would be the loss of life early in the 
program. Such a disaster will always be tragic, but it 


could also result in public castigation of the agency and 
possible program abandonment. If this were to be 
attributable to design integration failures, it would be not 
only tragic but unconscionable. 

DEVELOPMENT OF THE DOCUMENT 

Development of requirements for any project, large or 
small, demands an understanding of the mission; the 
basic question is, “what do we want this system to do?” 

A Concept of Operations document is a useful way to 
establish mission goals. It is recommended that this be 
the first step, and that development of subsystem (in this 
case, robotic) mission scenarios be based on this 
Concept of Operations. The scenarios will eventually 
take the form of Critical Task Analyses 4 for the robots 
involved in a particular mission. Here, the word 
“mission" is used to indicate a type of short-term activity 
of a particular robot or class of robots. Thus a mission 
might be the collection of subsurface material from the 
centers of all lunar craters within eighty kilometers of a 
lunar base and the return of the material. This mission 
would not be accomplished in a single sortie, and it 
would be established that the robot(s) will be working 
collaboratively with humans. This sort of scenario 
definition will both establish a set of basic requirements 
{ e.g ., power needs, lower limits for load-carrying 
capacities, thermal environments, communication 
interfaces, et c.) and raise a set of questions that need to 
be further examined through trade studies (will the robot 
provide human transportation? will it provide human life 
support?). Note that this activity brings to light 
requirements on both side of the interface between the 
robot and its environment. Thus, if it is decided that the 
robot will provide life support to the human during the 
translocation phase of the mission, the requirements on 
the robot will be to provide power, gases, and fluids to 
the human's suit. It also requires that the human’s suit 
be designed to connect appropriately to the robot. 
Furthermore, the robot will need to be able to connect to 
the necessary depot interfaces at the station in order to 
recharge with consumables, and the depot will be 
required to provide said interfaces. 

This process will be iterative and will be followed for 
each scenario. The requirements that flow out of them 
would then be sorted by class and organized into 
sections within Volumes I & II of the RSIS. The process 
itself will be captured in Volume III. 

It should be apparent that the development of the RSIS 
is not a robotics-specialist task. While such subject- 
matter experts should be team members, the majority of 
the effort should fall on systems engineers with a 


background in human engineering. The issues dealt 
with by human system designers are exactly those faced 
by the systems of robots and the environments with 
which they will interact. Possibly more importantly, the 
design of human interface with these complex machines 
is likely the most critical part of the work. 

CONCLUSION 

In the next phase of exploration robots will be 
collaborative assistants to humans. These worker 
robots will be part of the most complex systems ever 
created by humans. Failure to properly integrate them 
into the exploratory systems will not simply be costly; it 
will likely lead to system failures that could result in 
mission failure, including loss of human life. A systems 
engineering perspective will support management of this 
risk. Specifically, the development of a Robotics 
Systems Integration Standard will support the proper 
management of the complexity in these exploration 
systems. 
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